1. Technical Field
The present invention relates to web service composition and invocation.
2. Discussion of the Related Art
Web Service Composition Using Planning
Automated planning can be used to create composite applications in compositional architectures, such as web services and stream processing. The applications are workflows composed of smaller modular components, such as service invocations or other (smaller) workflows.
In many scenarios, the components are service invocations (such as web service invocations or invocation of a method of a Java class), and can be described in terms of their data effects and preconditions. In particular, we assume that a description (such as Web Services Description Language (WSDL) or Java object code with optional metadata annotations) of each service specifies the input requirements of the service (such as data type, semantics, access control labels, etc.). We refer to these input requirements as preconditions of service invocation, or simply preconditions. The description also specifies the effects of the service, describing the outputs of the service, including information related to data type and semantics of the output, for example. In general, a service description may describe outputs as a function of inputs, so that the description of the output can only be fully determined once the specific inputs of the service have been determined. Note that in practical implementations the invocations can be synchronous, such as subroutine or Remote Procedure Call (RPC) calls, or asynchronous, such as asynchronous procedure calls or message exchange or message flow.
Under these assumptions, an automated planner can be used to automatically assemble workflows based on a user-provided description of the desired output of the application. The descriptions of the components are provided to the planner in the form of a domain description. The planner can also take into account the specification of available primal inputs to the workflow, if not all inputs are available for a particular planning request.
The planner composes a workflow by connecting components, starting from the primal inputs. It evaluates possible combinations of components, by computing descriptions of component outputs, and comparing them to preconditions of components connected to the output. More than one component input can be connected to one component output or primal input. Logically, this amounts to sending multiple copies of data produced by the component output, with one copy sent to each of the inputs. In practical implementation, these do not have to be copies, and it is possible to pass data by reference instead of by value. The process terminates when an output of a component (or a set of outputs taken together) satisfy the conditions specified in the user requirement. Note that all conditions are evaluated at plan time, before any applications are deployed or executed.
If multiple alternative compositional applications can be constructed and shown to satisfy the same request, the planner may use heuristics and utility functions to rank the alternatives and selected preferred plans.
The application, once composed, is deployed in an execution environment and can be executed one or more times.
Examples of a planner and an execution environment are described in Zhen Liu, Anand Ranganathan and Anton Riabov, A Planning Approach for Message-Oriented Semantic Web Service Composition, in AAAI-2007.
Similar work has been done in the contexts of Stream Processing, Web Services and Grid Computing. In particular, the following papers describe different approaches to automatic composition of web services using planning: Narayanan, S., and McIlraith, S. 2002. Simulation, verification and automated composition of web services. In WWW'02; Sirin, E., and Parsia, B. 2004. Planning for Semantic Web Services. In SemanticWeb ServicesWorkshop at 3rd ISWC; and Traverso, P., and Pistore, M. 2004. Automated composition of semantic web services into executable processes. In ISWC'04.
An example of automated service composition using planning is described in commonly assigned U.S. application Ser. No. 11/970,262, filed Jan. 7, 2008, which includes a detailed description of service composition using a tag-based specification of processing goals.
Existing service composition approaches involve two steps. First, a composite service is composed, either manually or using automated tools such as planners. Then, the composite service is deployed in an application server environment, such as Websphere, and assigned an external invocation identifier, such as a Uniform Resource Locator (URL) and request interface. After the two steps are complete, the service is ready to be used and can be invoked by clients. This process, including repeated invocation, is illustrated in FIG. 1. The steps of receiving composition request (105), composition (110) and deployment (115) are usually performed by the automatic composition system, and the steps of receiving execution request (120) and service execution (125) are performed by the execution environment.
Note that in this process there is also an optional step of publishing the description of the composite service in a service registry.
This approach, however, requires human involvement when a new composition is created. The replacement service is again assigned an invocation identifier and a certain request interface.
This process introduces noticeable delay in updates of the service. In addition, when the composed service is hosted by a different party (provider) than the one owning the client that makes calls to the service, the clients must depend on the provider to make updates. Finally, the clients cannot easily create new compositions, and again require the services of the provider if new composition is needed.
Web Service Invocation
Web services are commonly described in WSDL (http://www.w3.org/TR/wsdl.html). A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints is separated from their concrete network deployment, which is described separately within the WSDL document in a service binding. Invocation of a web service described in WSDL requires identifying a service port and a corresponding binding, and subsequently contacting the service by sending a message to the port using the protocol and the contact information obtained from the binding. Note that any service called via this mechanism must have a corresponding WSDL document. Hence, for each composed service a WSDL document must be created before the service can be used by clients. Because of this, WSDL-based mechanisms are not used to address many problems in existing service composition.
Representing Composed Web Services
A number of languages for describing compositions of services have been developed. One example of such language is WS-Business Process Execution Language (WS-BPEL) described in WS-BPEL 2.0 specification (OASIS standard), http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf.
Composing services using languages such as BPEL requires describing details of service selection, composition and parameterization. Systems that implement web service composition using planning are easier to use since they require only a minimally sufficient high-level description of the service as input, and generate a detailed description of the composition in WS-BPEL or a similar language.